Understanding Windows Azure Roles

1. Role Instances

Let’s consider the boxes and arrows on the whiteboard. When you draw out your architecture, you probably have more than one “type” of box. Any site or service with serious usage is probably going to need more than one web frontend. Just like the “type” of box corresponds to a role in Windows Azure, the actual box corresponds to a role instance.

Note the use of the terms type and instance. The similarity to the same terms as used in object-oriented programming (OOP) is deliberate. A role is similar to a class/type in that it specifies the blueprint. However, the actual code runs in a role instance, which is analogous to an instantiated object.

Also note that there is a strict limitation of one role instance per virtual machine; there is no concept of multiple roles on the virtual machine. If you want to host more than one role on the same virtual machine, you’ll need to pack the code together into a single web role or worker role, and distribute the work yourself.

1.1. Role instances and the load balancer

In the boxes-and-diagrams version, how incoming traffic is routed to your machines completely depends on your network setup. Your infrastructure could have a mass of virtual local area networks (VLANs), software and hardware load balancers, and various other networking magic.

In Windows Azure, the relationship between role instances and incoming traffic is simple. As shown earlier in Figure 4-1, all role instances for a role are behind a load balancer. The load balancer distributes traffic in a strict round-robin fashion to each role instance. For example, if you have three web role instances, each will get one-third of the incoming traffic. This even distribution is maintained when the number of instances changes.

How does traffic directed toward foo.cloudapp.net end up at a web role instance? A request to a *.cloudapp.net URL is redirected through DNS toward a virtual IP address (VIP) in a Microsoft data center that your service owns. This VIP is the external face for your service, and the load balancer has the knowledge to route traffic hitting this VIP to the various role instances.

Each of these role instances has its own special IP address that is accessible only inside the data center. This is often called a direct IP address (DIP). Though you can’t get at these DIPs from outside the data center, these are useful when you want roles to communicate with each other. Later in this chapter, you’ll see the API that lets you discover what these IP addresses are used for with the other role instances in your service.

1.2. Controlling the number of instances

The number of role instances that your service uses is specified in the service configuration (that is, the ServiceConfiguration.cscfg file). Under each Role element, you should find an Instances element that takes a count parameter. That directly controls the number of role instances your service uses. Since this is part of the service configuration (and not the definition), this can be updated separately, and doesn’t require rebuilding/redeploying your package.

Example 1 shows a sample service configuration with one instance. You can specify the instance count separately for each role in your service.

Example 1. Sample service configuration

<?xml version="1.0"?>
<ServiceConfiguration serviceName="CloudService1"
 xmlns=
"http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings />
  </Role>
</ServiceConfiguration>

Note that all instances in your role are identical. Later in this chapter, you’ll see how to have roles on different virtual machine sizes. It is currently not possible to have role instances of the same role with different sizes.

Though changing the number of role instances is simple in the service configuration, it can take longer to update in the cloud than other service configuration changes. The reason behind this is that changing the instance count (or, to be specific, adding new instances) means that new machines must be found to run your code. Depending on the current state of the machine, some cleanup may be required before your code can be run on the new machines. Take this into account when making large changes to instance counts.

2. Role Size

Though this wasn’t available as part of the initial Windows Azure release, the ability to specify the size of the virtual machine was added in late 2009. To be specific, you get to choose how many “slices” of the machine you want combined. Each size has a different billing rate. As always, consult the Windows Azure website for up-to-date information on the latest billing rates.

To specify the size for your role, use the vmsize attribute in the service definition file. Since this is a service definition attribute, you cannot change this dynamically without reuploading your package, or doing a service upgrade.

Example 2 shows a sample configuration file with the virtual machine size set to “extra large” (the largest virtual machine size available). As of this writing, there are four virtual machine sizes, ranging from Small to ExtraLarge.

Example 2. Virtual machine size

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Test"
 xmlns=
"http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="Test"  vmsize ="ExtraLarge">
    <ConfigurationSettings/>
  </WorkerRole>
</ServiceDefinition>

Table 2 lists all the virtual machine sizes and their equivalent configuration if they were real machines. This is meant to act as a rule of thumb to give you an idea of the kind of performance you can expect. As you go from small to large, you get a bigger slice of the CPU, RAM, and hard disk, as well as I/O benefits. However, you should do performance and load testing with your target workload before picking the virtual machine size on which you want to run your code.